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(57) Abstract 



The present invention includes a mobile device (3) which 
provides the user with the ability to schedule a meeting request 
from the mobile device (3) itself. The mobile device (3) creates an 
object representative of the meeting request and assigns the object 
a global identification number which uniquely identifies the object 
to other devices (4, 10, 13) which encounter the object In addition, 
the mobile device (3) in accordance with one aspect of the present 
invention provides a property in the object which is indicative 
of whether the meeting request has already been transmitted. In 
this way, other devices (4, 10, 13) which encounter the meeting 
request are capable of identifying it as a unique meeting request, 
and of determining whether the meeting request has already been 
transmitted, in order to alleviate the problem of duplicate meeting 
request transmissions. 
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GENERATING MEETING REQUESTS AND GROUP 
SCHEDULING FROM A MOBILE DEVICE 

BACKGROUND OF THE INVENTION 
Mobile devices are small electronic computing 
5 devices often referred to as personal digital 
assistants. One such mobile device is sold under the 
trade name Handheld PC (or "H/PC") based on a Windows 
CE brand operating system provided by Microsoft 
Corporation of Redmond, Washington. While a wide 
10 variety of computing tasks and applications can be 
performed by such mobile devices, personal information 
managers (PIMs) are particularly well suited to mobile 
devices . 

PIMs typically comprise applications which enable 
15 the user of the mobile device to better manage 
scheduling and communications, and other such tasks. 
' Some commonly available PIMs include scheduling and 
calendar pi-ograms, task lists, address books, and 
electronic mail (e-mail) programs. Some commonly 

2 0 commercially available PIMs are sold under the brand 

names Microsoft Schedule+ and Microsoft Outlook and 
are commercially available from Microsoft Corporation 
of Redmond, Washington. For purposes of this 

discussion, PIMs shall also include separate 
25 electronic mail applications, such as that available 
under the brand name Microsoft Exchange. 

It is also common for mobile devices to be used 
in conjunction with a desktop computer. For example, 
the user of a mobile device may also have access to, 

3 0 and use, a desktop computer at work, at home, or both. 

A user may typically run the same types of PIMs on 
both the desktop computer and the mobile device 
(although the particular versions of the PIMs may be 



SUBSTITUTE SHEET (RULE 26) 



WO 99/22324 PCT/US98/22413 



2 

somewhat different from the desktop computer to the 
mobile device) . Thus, it is quite advantageous for 
the mobile device to be designed to be couplable to 
the desktop computer to exchange information with, and 
5 share information with, the desktop computer. 

The user may also typically make changes to the 
PIMs both on the mobile device, and at the desktop. 
Therefore, it is advantageous for the PIMs on both the 
mobile device and the desktop to contain the most up- 

10 to-date information, regardless of whether recent 
changes to the PIMs have been made on the mobile 
device or the desktop computer. The process of 
coupling the mobile device with the desktop computer, 
and integrating the information stored by the PIMs on 

15 the mobile device and the desktop computer such that 
the two contain the same updated information is 
referred to as synchronization. 

Conventional PIMs which support electronic 
calendaring and scheduling features (collectively 

20 referred to as a scheduler, or as a scheduling 
application) are traditionally supported on desktop 
computers. Such PIMs provide the ability of the user 
to schedule a meeting request for one or more desired 
attendees . 

25 In order to generate a meeting request, the user 

typically interacts with the scheduling application 
through a user interface. The user interface provides 
the user with a plurality of selectable options to 
parameterize the meeting request. For example, the 

30 user interface typically allows the user to pick a 
date and time (and often a place) on which the meeting 
is to be held. The user interface also typically 
allows the user to select a group of attendees that 
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the user wishes to attend the meeting, to enter some 
textual description of the meeting, and to specify 
whether the meeting is for only a single date, or is a 
recurring meeting (i.e., whether the meeting is to 
5 occur only on one date, the 15 th of every month, the 
first Monday of every month, every Monday, etc.). 

Based on this information, the scheduling 
application creates an object which is representative 
of the meeting and enters it on the user's calendar as 
10 an appointment. Such objects are typically defined by 
a number of properties, some of which are defined by 
the user input information which the user provides 
while generating the meeting request. The meeting 
object also contains a critical time stamp (UTC) which 
15 is updated whenever a critical change is made to the 
meeting object, such as changes to the start or end 
date or time, changes in the location, etc. 

Since other people are identified as attendees, 
the appointment entered on the calendar is viewed as a 
20 meeting and the scheduling application typically calls 
methods exposed by an electronic mail application in 
accordance with messaging application programming 
interfaces (MAPI), or other APIs which are a set of 
well documented, published interfaces commercially 
25 available from the Microsoft Corporation of Redmond, 
Washington. 

In response, the electronic mail application 
creates another object (an electronic mail meeting 
request object) indicative of the meeting request and 
3 0 the electronic mail application (or suitable 
transport) formats this electronic mail meeting 
request object into a well defined electronic mail 
message suitable for transmission. In doing so, the 



SUBSTITUTE SHEET (RULE 26) 



WO 99/22324 



PCT/US98/22413 



critical time stamp from the meeting object is also 
placed in the electronic mail meeting request object. 

The electronic mail application then interacts with 
a specified transport and transports the electronic 
5 mail meeting request object to a network which routes 
it to the designated attendees. In doing so, the 
electronic mail application typically accesses an 
address book stored in a database to obtain the fully 
qualified electronic mail address for the attendees. 

10 This is also typically done by calling MAPI or other 
suitable API methods associated with the database 
storing the address book. The generation of the 
meeting object and the creation of the electronic mail 
meeting request object will be referred to herein 

15 collectively as creating a meeting request. 

The potential attendees then typically respond to 
the meeting . request . In doing so, the originator's 
critical time stamp is sent back (unmodified) along 
with the response. The response also includes a 

20 recipient critical time stamp and an indication of the 
recipient's response (e.g., accept, decline, 
tentative, etc.). The recipient critical time stamp 
is updated by the recipient (potential attendee) 
whenever a critical change is made by the recipient. 

25 This allows the user to reliably order receipt of 
multiple versions of the same meeting (e.g., where the 
originator changes the time, date or location of the 
meeting such that multiple meeting requests are 
generated) . It also allows the originator to reliably 

3 0 order receipt of responses and ensure that each 
response correlates to the most recent version of the 
meeting . 

The response is then transmitted 'back to the 
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originator (e.g., the sending computer). The 
electronic mail application and scheduling application 
on the originator then typically process the response 
(or responses) accordingly. For example, the 

5 originator stores, for each recipient (or potential 
attendee) the recipient critical time stamp in a table 
along with each recipient's response code (which is 
indicative of the accept, decline, tentative 
response) . The two commercially available PIMs 
10 identified above (the Microsoft Schedule+ and 
Microsoft Outlook brand PIMs) are examples of PIMs 
which support the features discussed above. 

Meeting cancellations, and exceptions to 
recurring meeting must also be handled. For example, 
15 the PIMs may allow scheduled meetings to be cancelled, 
and allow a variety of exceptions to a recurring 
meeting pattern. 

Scheduling of meeting requests as described above 
has, to date, only been supported by desktop computers 
20 or laptop computers which are fitted with a hard disk 
drive or other high capacity memory mechanisms, or by 
low intelligence terminals which are permanently 
attached to a server or other similar computer which, 
itself, contains a high capacity storage device. The 
25 ability to schedule a meeting request from a mobile 
device is simply unavailable. While some current 
mobile devices are provided with PIMs that allow the 
user to view meeting requests, and to view meetings 
which have already been scheduled, current mobile 
30 devices do not allow the user to generate a meeting 
request from the mobile device itself. 

A number of significant obstacles present 
themselves when attempting to provide the user with 
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the capability of generating a meeting request from a 
mobile device. Meeting cancellations and exceptions 
to recurring meetings must be handled. Also, a 
significant problem arises with respect to the 
5 possibility of transmitting duplicate meeting 
requests. While duplicate meeting requests as 

described below may not necessarily be created with 
all PIMs, they do present a potential problem which 
must be considered. For example, if the user of the 

10 mobile device were able to generate a meeting request, 
a meeting object would first be entered on the 
calendar of the mobile device. The electronic mail 
application on the mobile device would then create a 
corresponding electronic mail meeting request object. 

15 The next time the mobile device was synchronized 

with the desktop computer, the meeting object would be 
synchronized with the calendar object store on the 
desktop computer and the electronic mail, meeting 
request object would be synchronized to the desktop 

2 0 outbox. The desktop computer, would recognize the 
electronic mail meeting request object in its outbox, 
format it for transmission, and transmit it over the 
network. Further, synchronizing the meeting object to 
the calendar of the desktop computer may result in 

25 another electronic mail meeting request object being 
created and transmitted by the desktop computer. This 
would result in duplicate electronic mail meeting 
request objects being created (one by the mobile 
device, and one by the desktop computer after 

30 synchronization) and transmitted. Under that 

scenario, potential attendees would receive two or 
more meeting requests, and may respond to both. This 
would create duplicate responses to what* was intended 
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to be a single meeting request. 

A similar problem may occur if a meeting request 
were generated in a conventional manner (on a desktop 
computer) for instance, and was then synchronized to a 

5 mobile device having the capability of generating and 
transmitting meeting requests. The meeting object on 
the desktop calendar would be synchronized to the 
calendar of the mobile device. The mobile device 
might then recognize the meeting object synchronized 
10 from the desktop, and create an electronic mail 
meeting request object and attempt to transmit the 
object. This would result in substantially the same 
problem duplicate meeting requests and duplicate 

responses for what was intended to be a single meeting 

15 request . 

Further, if the user of the mobile device coupled 
the mobile device for synchronization with more than 
one desktop computer (e.g., a home computer and work 
computer, if the mobile device were provided with thas 
20 capability) the same problem would result. In that 
instance, and using conventional architecture, both 
desktop computers would synchronize with, and 
recognize, the meeting object and the electronic mail 
meeting request object from the mobile device. The 
25 desktop computers would both potentially create 
additional electronic mail meeting request objects and 
transmit them to the potential attendees. Again, 
this would result in many different meeting requests 
and responses being transmitted for what was intended 
30 to be only a single meeting request. 

In addition, if mobile devices were provided with 
the capability of being connected directly to one 
another, and communicating with one anbther, without 
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going through a desktop or similar computer, the 
meeting request could be generated by one mobile 
device, responded to by another mobile device, and 
scheduled on both mobile devices. However, the next 
time the first mobile device is synchronized with the 
desktop computer, that computer might again recognize 
the meeting object synchronized from the calendar of 
the mobile device, create another electronic mail 
meeting request object and transmit the electrons 
nail meeting request object. Thus, a significant 
problem potentially exists with respect to the 
generation of multiple meeting requests. 

Of course, similar problems also result from 
critical changes to the meeting object on either the 
desktop computer or the mobile device. This will 
cause unwanted duplicate electronic mail meeting 
requests in a similar fashion. 

Additional problems also present themselves 
simply by the fact that conventional mobile devices 
have a memory capacity which is significantly less 
than that of a desktop computer or similar computer. 
Thus, problems arise with respect to storing address 
books on the mobile device itself which contain the 
fully qualified electronic mail address of all 

25 potential attendees. 

Further obstacles present themselves because many 
desktop computers on which the meeting request must be 
processed have different scheduling applications. 
Therefore, the meeting request generated by the mobile 
30 device may be incompatible with scheduling 
applications which it encounters. 

in addition, localization of meeting requests can 
present a problem. For instance, in some localities, 



20 
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it is conventional, when writing a date, to place the 
month first, the day second and the year third. In 
other localities, other orders are conventional. 
Further, a textual description which describes the 
5 meeting, and which accompanies the meeting request, 
may need to be rearranged to conform to local 
convention. Also, meeting requests can be generated 
in one time zone and transmitted to recipients in 
other time zones. This can tend to be confusing. 
10 The present invention addresses some or all of 

these obstacles. 

SUMMARY OF THE INVENTION 
The present invention includes a mobile device 
which provides the user with the ability to schedule a 
15 meeting request from the mobile device itself. The 
mobile device creates an object representative of the 
meeting request and assigns the object a global 
identification number which uniquely identifies the 
object to other devices which encounter the object. In 
20 this way, other devices which encounter the meeting 
request are capable of identifying it as a unique 
meeting request in order to alleviate the problem of 
duplicate meeting request transmissions. 

In accordance with another preferred feature of 
25 the present invention, an electronic mail application 
or calendar application on the mobile device obtains a 
fully qualified electronic mail address for the 
potential attendees from an abridged address book or 
directory stored on the mobile device itself. This 
3 0 alleviates problems associated with the storage 
capacity of the mobile device. 

In accordance .with another preferred embodiment 
of the present invention, the mobile device creates 
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the meeting object and the electronic mail meeting 
request object using a set of properties which are 
supported by a plurality of PIMs that may receive the 
objects - This provides compatibility with an 
increased number of devices which are likely to 
encounter the objects. 

In accordance with yet another preferred feature 
of the present invention, localizers implement a 
plurality of templates on the mobile device which are 
used in formatting the properties of the objects 
associated with the meeting request. A data stream 
representative of the meeting request is parsed by the 
mobile device and placed in pre-defined fields in the 
appropriate templates so that the text viewed by the 
15 user of the mobile device more closely conforms to 
local convention. In addition, time zone information 
is also included in one embodiment. 

RRTEF DESCRIPTION THE DRAWINGS 
FIG. 1 is a block diagram illustrating a basic 
20 environment of the present invention. 

FIG. 2 is a. block diagram of one embodiment of a 
conventional desktop computer used in conjunction with 
a mobile device in accordance with the present 
invention . 

25 FIG. 3 is a simplified pictorial illustration of 

one embodiment of a mobile device in accordance with 
the present invention. 

FIG. 4 is a simplified block diagram of one 
embodiment of the mobile device shown in FIG. 3. 

FIG. 5 is an architectural block diagram 
illustrating one embodiment of portions of the desktop 
computer shown in FIG. 2 and the mobile device shown 
in FIGS. 3 and 4 to illustrate synchronization of 



30 
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information stored in object stores on the desktop 
computer and the mobile device in accordance with the 
present invention. 

FIG. 6 is an architectural block diagram 
illustrating one embodiment of portions of the desktop 
computer shown in FIG. 2 and the mobile device shown 
in FIGS. 3 and 4 to illustrate the generation and 
transmission of a meeting request. 

FIG. 7 is a flow diagram illustrating the 
generation of a meeting request in accordance with one 
preferred embodiment of the present invention. 

FIG. 8 is a flow diagram illustrating the 
handling of responses to a meeting request on the 
mobile device shown in FIGS. 3 and 4 in accordance 
15 with one preferred embodiment of the present- 
invention . 

FIG. 9 is a flow diagram illustrating the 
handling of responses to a meeting request on the 
desktop computer shown in FIG. 2 in accordance with 
20 one preferred embodiment of the present invention. 

FIG. 10 is a flow diagram illustrating the use of 
a localizer to localize the textual description of a 
meeting request in accordance with one preferred 
embodiment of the present invention. 
25 figs. HA and 11B illustrate one embodiment of a 

template used to localize the textual description of a 
meeting request in accordance with the present 
invention . 

TVF.T&TT.F.n DESCFTPTTON OF T HK PREFERRED EMBODIMENTS 
30 OVERVIEW 

FIG. 1 is a block diagram of a typical system or 
environment 2 in which the present invention operates. 
Environment 2 includes mobile device 3" and desktop 
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computer 4. FIG. 1 also illustrates that mobile 
device 3 can optionally be separately coupled to 
another mobile device 10 or another desktop computer 
13 . 

5 Mobile device 3 includes an application program 5 

and an object store 6. Desktop computer 4 also 
includes an application program 7 and an object store 
8. Mobile device 10 includes an application program 
11 and object store 12. Further, desktop computer 13 
10 includes an application program 14 and an object store 
15 . 

Mobile device 3 is couplable to desktop computer 
4, mobile device 10 or desktop computer 13 by one of a 
plurality of connection mechanisms 9. The operation 

15 of desktop computers 4 and 13 and the operation of 
mobile devices 3 and 10 are preferably similar. 
Therefore, for the sake of simplicity, the present 
description proceeds only with respect to mobile 
device 3 and desktop computer 4 . 

20 In one preferred embodiment of the present 

invention, application program 7 on desktop 4 is a 
personal information manager (PIM) which supports 
electronic mail messaging, scheduling and calendaring 
and an address book containing contact information. 

25 PIM applications are not always integrated. For 

instance, some scheduling programs do not contain 
electronic mail features, but interface with whatever 
electronic mail program is provided, and vice versa. 
Of course, PIM 7 (whether it be a single application, 

30 a single integrated application or multiple interfaced 
applications) can be configured to support a wide 
variety of other features, such as task lists and 
personalized address books, to name a few. However, 
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for the sake of clarity, only features relating to 
electronic mail messaging, scheduling and calendar 
features, and address book features are discussed in 
detail with respect to the present invention. 

Object store 8 is a memory which is configured to 
store a plurality of individual records or objects, 
each comprising a plurality of fields or properties 
related to the above-mentioned features. In one 
preferred embodiment, PIM 7 is a program, such as that 
available under the commercial designation Microsoft 
Outlook 97, and object store 8 is configured to store 
objects, each of which has a plurality of properties 
which can be associated with electronic mail 
messaging, scheduling and calendaring, and contact 

15 information. 

For example, some properties included in an 
object associated with electronic mail messaging 
include the sender's name, the recipient's name, text 
messages, an indication of whether attachments are 
attached to any given electronic mail message, and 
possibly other similar properties. Also, some 

properties associated with scheduling and calendaring 
include critical time stamp information, date and time 
information, potential attendees, recurrence 
properties which describe recurrent meetings or 
meeting requests, and a textual description of the 
meeting request. Some properties associated with 
contact information include the proper names, or 
familiar names, of those in the contact list, the 
addresses and telephone numbers of those listed, and 
the fully qualified electronic mail address for those 
in the list. Any number of other properties can also 
be included. Desktop computer 4 'executes the 
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application program identified as PIM 7 to maintain 
objects stored in object store 8. 

The application program designated as PIM 5 for 
mobile device 3 is a similar PIM to that stored on 
desktop computer 4. Object store 6 on mobile device 3 
is configured to store a plurality of individual 
records or objects, each comprising a plurality of 
fields or properties related to the above-mentioned, 
supported features. As with PIM 7, PIM 5 can also 
support a wide variety of other features. However, 
for the sake of clarity, only those features related 
to the present invention are discussed in detail 
herein. 

In one illustrative embodiment, each object in 
15 object store 6 comprises the same set of properties 
stored in object store 8 for related messages, or a 
subset of those properties. In addition, the objects 
stored in object store 6 also preferably include a 
critical change time stamp, properties which indicate 
whether potential attendees identified in a meeting 
request have responded, and a global identification of 
each individual meeting request (discussed in greater 
detail below) . Mobile device 3 executes PIM 5 to 
maintain the objects in object store 6. 

In the illustrative embodiment, each object 
stored in object store 8 is also stored in object 
store 6. However, there are actually two instances of 
each object (one in object store 6 and one in object 
store 8). Thus, when a user changes one instance of 
the object stored in either store 6 or store 8, the 
second instance of that object in the other of stores 
6 and 8 is preferably updated the next time mobile 
device 3 is connected to desktop computer 4 so that 
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both instances of the same object contain up-to-date 
data. This is referred to as synchronization. 

In order to accomplish synchronization, 
synchronization components run on both mobile device 3 
5 and desktop computer 4. The synchronization 

components communicate with PIMs 5 and 7 on mobile 
device 3 and desktop computer 4 through well defined 
interfaces to manage communication and 

synchronization . 

10 xhe components of mobile device 3 and desktop 

computer 4 communicate with each other through any 
suitable, and commercially available, communication 
link 9, and using a suitable communications protocol. 
For instance, in one preferred embodiment, mobile 

15 device 3 is connectable to desktop computer 4 with a 
physical cable which communicates using a serial 
communications protocol. Other communication 

mechanisms are also contemplated by the present 
invention, such as infrared (IR) communication, direct 

20 modem communication, remote dial-up networking 
communication, communication through commercially 
available network cards (i.e., using TCP/IP), remote 
access services (RAS) , wireless modem, wireless 
cellular digital packet data (CDPD) , or other suitable 

25 communication mechanisms. 

FIG. 2 and the related discussion are intended to 
provide a brief, general description of a suitable 
desktop computer 4 in which portions of the invention 
may be implemented. Although not required, the 

3 0 invention will be described, at least in part, in the 
general context of computer- executable instructions, 
such as program modules, being executed by a personal 
computer 4 or mobile device 3. Generally, program 
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modules include routine programs, objects, components, 
data structures, etc. that perform particular tasks or 
implement particular abstract data types. Moreover, 
those skilled in the art will appreciate that desktop 
5 computer 4 may be implemented with other computer 
system configurations, including multiprocessor 
systems, microprocessor-based or programmable consumer 
electronics, network PCs, minicomputers, mainframe 
computers, and the like. The invention may also be 

1C practiced in distributed computing environments where 
tasks are performed by remote processing devices that 
are linked through a communications network. In a 
distributed computing environment, program modules may 
be located in both local and remote memory storage 

15 devices. Examples of distributed programs include 
those available under the commercial designations 
Exchange, Schedule* and MS Mail, all available from 
Microsoft Corporation. 

With reference to FIG. 2, an exemplary system for 

20 implementing desktop computer 4 includes a general 
purpose computing device in the form of a conventional 
personal computer 4, including processing unit 21, a 
system memory 22, and a system bus 23 that couples 
various system components including the system memory 

25 to the processing unit 21. The system bus 23 may be 
any of several types of bus structures including a 
memory bus or memory controller, a peripheral bus, and 
a local bus using any of a variety of bus 
architectures. The system memory includes read only 

30 memory (ROM) 24 and random access memory (RAM) 25. 

A basic input/output system (BIOS) 26, containing 
the basic routine that helps to transfer information 
between elements within the desktop computer 4, such 
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as during start-up, is stored in EEPROM which is part 
of ROM 24. The desktop computer 4 further preferably 
includes a hard disk drive 27 for reading from and 
writing to a hard disk (not shown) , a magnetic disk 
5 drive 28 for reading from or writing to removable 
magnetic disk 29, and an optical disk drive 3 0 for 
reading from or writing to a removable optical disk 31 
such as a CD ROM or other optical media. The hard 
disk drive 27, magnetic disk drive 28, and optical 
10 disk drive 3 0 are connected to the system bus 23 by a 
hard disk drive interface 32, magnetic disk drive 
interface 33, and an optical drive interface 34, 
respectively. The drives and the associated computer- 
readable media provide nonvolatile storage of computer 
15 readable instructions, data structures, program 
modules and other data for the desktop computer 4. 

Although the exemplary environment described 
herein employs a hard disk, a removable magnetic disk 
2 9 and a removable optical disk 31, it should be 
2 0 appreciated by those skilled in the art that other 
types of computer readable media which can store data 
that is accessible by a computer, such as magnetic 
cassettes, flash memory cards, digital video disks 
(DVDs), Bernoulli cartridges, random access memories 
25 (RAMs) , read only memory (ROM), and the like, may also 
be used in the exemplary operating environment. 

A number of program modules may be stored on the 
hard disk, magnetic disk 29, optical disk 31, ROM 24 
or RAM 25, including an operating system 35, one or 
30 more application programs 36 (which include PIMs 7) , 
other program modules 37, and program data 38. A user 
may enter commands and information into the desktop 
computer 4 through input devices such aT3 a keyboard 
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40, pointing device 42 and microphone 62. Other input 
devices (not shown) may include a joystick, game pad, 
satellite dish, scanner, cr the like. These and other 
input devices are often connected to the processing 
5 unit 21 through a serial port interface 46 that is 
coupled to the system bus 23, but may be connected by 
other interfaces, such as a sound card, a parallel 
port, a game port or a universal serial bus (USB) . A 
monitor 47 or other type of display device is also 
10 connected to the system bus 23 via an interface, such 
as a video adapter 48. In addition to the monitor 47, 
desktop computers may typically include other 
peripheral output devices such as speaker 45 and 
printers . 

15 The desktop computer 4 may operate in a networked 

environment using logic connections to one or more 
remote computers (other than mobile device 3), such as 
a remote computer 49. The remote computer 49 may be 
another personal computer, a server, a router, a 

2 0 network PC, a peer device or other network node, and 
typically includes many or all of the elements 
described above relative to desktop computer 4, 
although only a memory storage device 50 has been 
illustrated in FIG. 2. The logic connections depicted 

2 5 in FIG. 2 include a local area network (LAN) 51 and a 

wide area network (WAN) 52. Such networking 

environments are commonplace in offices, enterprise- 
wide computer network intranets and the Internet. 

When used in a LAN networking environment, the 

3 0 desktop computer 4 is connected to the local area 

network 51 through a network interface or adapter 53. 

When used in a WAN networking environment, the 
desktop computer 4 typically includes a* modem 54 or 
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other means for establishing communications over the 
wide area network 52, such as the Internet. The modem 
54, which may be internal or external, is connected to 
the system bus 23 via the serial port interface 46. 

5 In a network environment, program modules depicted 
relative to desktop computer 4, or portions thereof, 
may be stored in the remote memory storage devices. 
It will be appreciated that the network connections 
shown are exemplary and other means of establishing a 

10 communications link between the computers may be used. 

Desktop computer 4 runs operating system 35 that 
is typically stored in non-volatile memory 24 and 
executes on the processor 21. One suitable operating 
system is a Windows brand operating system sold by 

15 Microsoft Corporation, such as WINDOWS 95 or WINDOWS 
NT, operating systems, other derivative versions of 
WINDOWS brand operating systems, or another suitable 
operating system. Other suitable operating systems 
include systems such as the Macintosh OS sold from 

20 Apple Corporation, and the OS/2 Presentation Manager 
sold by International Business Machines (IBM) of 
Armonk, New York. PIM 7 is preferably stored in 
program module 37, in volatile memory or non-volatile 
memory, or can be loaded into any of the components 

25 shown in FIG. 2 from a floppy diskette 29, CDROM drive 
31, downloaded from a network via network adapter 53, 
or loaded using another suitable mechanism. 

A dynamically linked library (DLL) , comprising a 
plurality of executable functions is associated with 

30 PIM 7 for execution by processor 21. Interprocessor 
and intercomponent calls are facilitated using the 
component object model (COM) as is common in programs 
written for MICROSOFT WINDOWS brand operating systems. 
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Briefly, when using COM, a software component such as 
a DLL has a number of interfaces. Each interface 
exposes a plurality of methods, which can be called 
individually to utilize different services offered by 
5 the software component. In addition, interfaces are 
provided such that methods or functions can be called 
from other software components which optionally 
receive and return one or more parameter arguments. 

In general, the DLL associated with PIM 7 is 
10 designed specifically to work in conjunction with PIM 
7 and to expose desktop synchronization interfaces 
that function as described in more detail in the 
above - referenced co-pending U.S. patent application 
according to a synchronization protocol. The DLL, in 
15 turn, calls interfaces exposed by PIM 7 in order to 
access data representing individual properties of 
objects maintained in object store 8. Object store 8, 
of course, can reside in any one of the suitable 
memory components described with respect to FIG. 2. 
20 FIG. 3 is a pictorial illustration of one 

preferred embodiment of a mobile device 3 which can be 
used in accordance with the present invention. Mobile 
device 3, in one preferred embodiment, is a desktop 
assistant sold under the designation H/PC and being 
25 based on, for example, the WINDOWS CE BRAND operating 
system provided by Microsoft Corporation. In one 
preferred embodiment, mobile device 3 is housed in a 
housing which fits comfortably in the hand of 
typical user. Mobile device 3 has some components 
30 which are similar to those of desktop computer 4. For 
instance, in one preferred embodiment, mobile device 3 
includes a miniaturized keyboard 82, display 84, and 
stylus 86. Of course, other configurations, such as 
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without keyboards, can also be used. 

In the embodiment shown in FIG. 3, display 84 is 
a liquid crystal display (LCD) which uses a contact - 
sensitive display screen in conjunction with stylus 
5 86. Stylus 86 is used to press or contact the display 
84 at designated coordinates to accomplish certain 
user input functions. Of course, other user input 
configurations can be used as well. For example, user 
input mechanisms could be included such as a keypad, a 
10 track ball, and other various types of miniaturized 
keyboards, or the like. In addition, mobile device 3 
may not be embodied as the H/PC brand of digital 
assistant, but could also be implemented as another 
type of personal digital assistant (PDA) , another 
15 personal organizer, a palm top computer, or a similar 
computerized notepad device. 

FIG. 4 is a more detailed block diagram of mobile 
device 3. Mobile device 3 preferably includes 
microprocessor 88, memory 90, input/output (I/O) 
20 components 92 (which include keyboard 82 and touch 
sensitive screen 84), optional expansion slots 93 
(which can be used for plugging in such things as PC 
cards, compact flash memory, etc.) and serial 
interface 94. In the illustrative embodiment, these 
25 components of mobile device 3 are coupled for 
communication with one another over a suitable bus 96. 

In the illustrative embodiment, memory 90 is 
implemented as non-volatile electronic memory such as 
a random access memory (RAM) with a battery back-up 
3 0 module (not shown) such that information stored in 
memory 90 is not lost when the general power to mobile 
device 30 is shut down. A portion of memory 90 is 
preferably allocated as addressable memory for program 
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execution, while another portion of memory 90 is 
preferably used to simulate storage on a disk drive. 

Memory 90 includes operating system 98 and 
application (or PIM) 5. Operating system 98, during 
5 operation, is preferably loaded into, and executed by, 
processor 88 from memory 90. Operating system 98, in 
one preferred embodiment, is the Windows CE brand 
operating system. The operating system 98 is 

preferably designed for mobile devices, and implements 

10 database features which can be utilized by PIM 5 
through a set of exposed application programming 
interfaces and methods. The objects in object store 6 
are preferably maintained by PIM 5 and operating 
system 98, at least partially in response to calls to 

15 the exposed application program interfaces and 
methods . 

It should be noted that PIM 5 is not necessarily 
designed to be entirely compatible with PIM 7 which 
executes on desktop computer 4. For instance, there 

2 0 may not be a precise one-to-one matching between the 
properties of specific object types. Some properties 
supported by the electronic mail messaging features of 
PIM 5 may have no corresponding features in PIM 7 on 
desktop computer 4, and vise versa. 

25 OBJECT SYNCHRONIZATION 

Object synchronization is described here, 
briefly, to assist in understanding the present 
invention. 

FIG. 5 is an architectural block diagram 
30 illustrating one preferred embodiment of architectural 
components of mobile device 3 and desktop computer 4 
which are used in synchronizing objects stored in 
object store 6 on mobile device 3 and ob5ect store 8 
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on desktop computer 4. It should be noted that the 
synchronization architecture illustrated in FIG. 5 is 
but one preferred embodiment and others could be used 
as well. Further, the synchronization operation can 
be carried out between any two coupled stores (such as 
those on any combination of pairs of computers 4 and 
13, and mobile devices 3 and 10). All that is 
required is a synchronization manager component, as 
described below, which directs synchronization of the 
two coupled stores. The synchronization manager can 
reside on either device, or both, or on a third 
computer coupled to the two stores. However, for the 
sake of simplicity, only the embodiment in which 
desktop computer 4 is coupled to mobile device 3 is 
15 described herein. Also, the present synchronization 
protocol is but one preferred embodiment, as another 
suitable protocol could be implemented on top of 
standard electronic mail protocols. 

In addition to PIM 5 and object store 6, mobile 
20 device 3 includes synchronization module 97 which, in 
turn, includes interface component 10 0, and 
synchronization manager 102. Mobile device 3 also 
includes communications component 94, remote 
application programming interface (RAPI) server 116, 
25 and electronic mail messaging transports 132, 134 and 
136 . 

Desktop computer 4 includes, in addition to PIM 7 
and object store 8, synchronization module 99 which, 
in turn, includes interface ' component 108, 
synchronization manager 110, reference store 112, and 
RAPI component 114. Desktop computer 4 also includes 
communications component 115. 

Generally, in the embodiment illustrated in FIG. 



30 
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5, synchronization manager 110 executes on desktop 
computer 4 and orchestrates synchronization between 
objects in object store 6 in handheld device 3, and 
objects in object store 8 in desktop computer 4. 
5 Synchronization manager 110 also maintains reference 
store 112 apart from desktop object store 8 as is 
described in greater detail below. Synchronization 
manager 110 implements the synchronization protocol to 
allow a comparison between corresponding objects 
10 stored in object store 6 in mobile device 3 and object 
store 8 in desktop computer 4, to receive objects from 
object store 8, and to update objects in object store 
8. The synchronization protocol also facilitates the 
retrieval of objects stored in object store 6 in 
15 mobile device 3 through synchronization interface 
component 100 and synchronization manager 102, as well 
as communications component 94. 

On the side of mobile device 3, the 
synchronization interface component 100 exposes 
20 application programming interfaces which 

synchronization manager 102 calls to read and store 
objects and object properties on object store 6. In 
general, the application programming interfaces allow 
the creation of databases for different types of 
25 objects, and allow application programs to write and 
read property names and values to and from respective 
objects within object store 6. 

As discussed with respect to FIG. 1, PIM 5 
executes on mobile device 3 and maintains object store 
30 6. PIM 7 executes on desktop computer 4 and maintains 
object store 8. There are many different ways which 
PIMs 5 and 7 can store objects in object stores 6 and 
8. However, in a preferred embodiment PIMs 5 and 7 
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create a distinct database for each object type. For 
example, different databases are created for meetings, 
contacts, tasks, electronic mail messages, etc. A 
predefined set of properties is supported for each 
5 object type, and each of the databases is assigned a 
name by the application program that creates it. 

In an alternative embodiment, the application 
programs in PIMs 5 and 7 may use a single database for 
all object types, with the first property of each 
10 object defining the type of object. In any case, 
objects are uniquely identified within mobile device 3 
and desktop computer 4 by object identifiers which are 
independent of the names assigned by the application 
programs creating the object. 
15 Synchronization manager 110 is not necessarily 

closely associated with PIM 7. Rather, it is an 
independent component which synchronizes objects from 
any application program that supports the appropriate 
desktop synchronization interfaces. The specific 
20 synchronization interfaces are described in greater 
detail in the co-pending patent application 
incorporated above . Communication components 94 and 
115 implement serial communications between the 
computers using suitable link 9. 
25 Synchronization manager 110 communicates with PIM 

7 and accesses object store 8 through synchronization 
interface component 108. Synchronization interface 
component 108 corresponds generally to a DLL discussed 
with respect to FIG. 2 above, and exposes one or more 
30 application program interfaces and methods. 

The interfaces and methods are described in 
greater detail in the co-pending patent application 
which is incorporated above by reference. Of these 
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interfaces, one of note is preferably of the form 
known as messaging application program interfaces 
(MAPI) developed and published by the Microsoft 
Corporation for Windows brand operating system 
5 platforms, but other suitable interfaces can be used 
as well. In one preferred embodiment, the MAPI 
exposed by component 108 is a C-language application 
programming interface which allows programmable access 
to features of an electronic mail messaging program 

10 known as MS Mail also commercially available from the 
Microsoft Corporation. In another preferred 

embodiment, the MAPI exposed by component 108 is a 
component object model based (COM-based) set of 
interfaces which is sometimes referred to as extended 

15 MAPI and includes a set of automation interfaces to 
messaging systems, f or use in Visual Basic and the 
like. However, synchronization interface component 
108 and the associated application program interfaces 
and methods can be any suitable synchronization 

20 interface components designed for any particular 
application in PIM 7. Because the application program 
interfaces are preferably standardized, they allow 
synchronization manager 110 to access and synchronize 
any number of different desktop PIMs, as long as the 

25 required interface methods are implemented for each 
PIM. 

Reference store 112 provides a mapping between 
instances of objects stored in object store 6 on 
mobile device 3 and objects stored in object store 8 
30 on desktop computer 4. Since the same object 
identifiers are not used by PIM 5 to identify objects 
on object store 6 as are used by PIM 7 to identify 
objects in object store 8, this mapping is -required. 
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Synchronization manager 110 maintains reference 
store 112 so that reference store 112 contains the 
identifying data segments corresponding respectively 
to a plurality of object instances in object store 8 
5 on desktop computer 4 that are to be synchronized with 
instances of the same object in object store 6 on 
mobile device 3. The identifying data segments are 
updated each time corresponding object instances have 
been synchronized. 
10 The exact composition of an identifying data 

segment which is used to identify the particular 
object instances are assignable by the developer of 
the desktop synchronization interface component 108 , 
and are then handled and stored by synchronization 
15 manager 110. The identifying data segments preferably 
include some sort of time stamp information which can 
be compared to determine whether an object has changed 
since the identifying data segment was last recorded 
in reference store 112. 
20 In addition to maintaining a plurality of 

identifying data segments, synchronization manager 110 
also maintains a list of object identifiers 
corresponding to objects maintained in object store 6. 
These identifiers are provided to synchronization 
25 manager 110 whenever a new object is added to object 

store 6 on mobile device 3. 

SYNCHRONIZATION PROTOCOL 

The exact protocol by which full synchronization 

is accomplished in accordance with one embodiment of 

3 0 the present system is described here briefly. The 

brief discussion of that protocol is helpful in 

understanding of the present invention. In order to 

synchronize objects, synchronization manager 110 first 
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creates two lists of handles which refer to particular 
objects. The term "handle" refers to a number or 
other identifier that can be used to uniquely identify 
an object and to access the object. Generally, a 
5 handle is valid for a particular time period or 
session, such as during the time when an object has 
been "opened." If the same object is opened again, 
its handle may be different. 

The first list of handles is obtained from 

10 reference store 112 and is indicative of objects which 
have been synchronized in the past and are identified 
in reference store 112. The second list of handles is 
a list which identifies the objects stored on object 
store 8. The two lists of handles are compared 

15 against one another to determine whether the same 
objects are stored in reference store 112 and object 
store 8 . 

If an object is identified in reference store 
112, but not in object store 8, that particular object 
20 has been deleted from the desktop 4 since the last 
synchronization. On the other hand, if an object is 
identified in object store 8, but it does not appear 
in reference store 112, then it has been added to the 
desktop since the last synchronization. In either 

25 case, synchronization manager 110 determines how to 
handle the object. In one preferred embodiment, those 
objects which have been deleted from desktop object 
store 8 are also deleted from reference store 112. 
Further, those which have been added to object store 8 

30 are also added to reference store 112. 

Synchronization manager 110 then determines 
whether any of the objects stored in object store 8 
have been modified at the desktop sin'ce the last 
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synchronization. In other words, if handles 

corresponding to the same object appear in both object 
store 8 and reference store 112, but they are not 
identical (such as the time stamp, a revision number, 
5 or another suitable identifying segment is not the 
same) that indicates that the object in object store 8 
has been modified since the last synchronization. 

Synchronization manager 110 then determines 
whether any objects stored in object store 6 on mobile 

10 device 3 have been added or modified since the last 
synchronization. To determine whether an object has 
been added to object store 6, synchronization manager 
110 compares the list of objects in reference store 
112 (which reflects all objects at the last 

15 synchronization) with a list of objects on object 
store 6 maintained by synchronization manager 102. To 
determine whether an existing object has been 
modified, synchronization manager 102 is configured to 
maintain a status bit associated with each object 

2 0 stored in object store 6. The status bit reflects 

whether the particular object associated with that bit 
has been changed since the last synchronization. If 
so, synchronization manager 102 notifies 

synchronization manager 110 of that change if device 3 
25 is then coupled to desktop computer 4, or simply logs 
the status bit and sends it to synchronization manager 
110 the next time device 3 is coupled to desktop 
computer 4 . 

It should be noted that none of these procedures 

3 0 require either synchronization manager 110 or 

synchronization manager 102 to be aware of the 
particular nature or format of the identifying data 
segments or of the objects to which they correspond. 
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Rather, interface components 100 and 108 are called 
upon for all actions that depend upon the actual 
content of the identifying data segments, and the 
content of the objects. It is up to the designer of 
those interfaces to define a format for the 
identifying data segments that allows the interfaces 
to perform their required functions. 

Once the changes, additions and deletions are 
determined by synchronization manager 110, the items 
are synchronized. In order to do this, 

synchronization manager 110 forms a list of objects 
which have been changed on either object store 8 or 
object store 6 and simply calls upon the respective 
synchronization interface components to update the 
15 outdated object. If the same object has been modified 
both on mobile device 3 and desktop computer 4, a 
conflict arises. Synchronization manager 110 resolves 
the conflicts by either prompting the user, or 
referencing profile information entered by the user 
2 0 during a set-up procedure which dictates which device 
the user wants to take precedence over the other, and 
in which instances. The process of setting up profile 
information is described in greater detail in the 
above- identification patent applications. 
25 Where an object has either been created at the 

desktop computer 4 or in the mobile device 3, that 
object needs to be exchanged with the other device. 
In the instance where mobile device 3 needs to obtain 
a new object from desktop computer 4, synchronization 
manager 110 calls an interface method known as "Set- 
Up" which specifies a handle for the object to be 
obtained from object store 8 in desktop computer 4 and 
transferred to object store 6 in mobile* device 3. 
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Once the handle is obtained, the method known as 
"GetPacket" is called repeatedly to retrieve a data 
stream which represents the object, and which is 
formatted by interface component 108. Synchronization 
5 manager 110 simply treats the data as a data stream 
which is retrieved and sent over link 9 to 
synchronization manager 102, and eventually to object 
store 6. The appropriate synchronization interface 
component 100 parses the data stream in order to * 
10 identify certain property values associated with 
properties corresponding to the object. Those 
properties are then stored in the object store 6. 

Finally, synchronization manager 110 updates the 
identifying data segments associated with either 
15 synchronized or exchanged objects and stores the 
updated data segments in reference store 112. 

It is worth noting that* the architecture 
described herein provides synchronization of objects 
associated with electronic mail messages, meetings or 
20 appointments, and contacts information, as well as 
other objects maintained by PIMs 5 and 7. Thus, using 
the above synchronization protocol, objects associated 
with these features are synchronized during the 
synchronization process. Synchronization manager 110 
25 detects any new objects in object store 8 which 
represent new electronic mail messages, meetings or 
appointments or contact information and causes those 
objects to be transferred to object store 6 on mobile 
device 3 for attention by the user of mobile device 3 . 
3 0 Further, if the user composes an electronic mail 

message or schedules a meeting (and therefore creates 
a meeting object and an electronic mail meeting 
request object) or enters contact information on 
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mobile device 3 using an appropriate application in 
PIM 5, the objects associated with those items are 
stored as new objects in object store 6. During 
synchronization, those new objects are transferred to 
5 desktop computer 4 and object store 8. 

MEETING REQUESTS 

FIG. 6 is an architectural block diagram 
illustrating one preferred embodiment of a mechanism 
by which meeting requests are generated. Mobile 

10 device 3 and desktop computer 4 are shown coupled to 
one another, as shown in FIG. 5. However, FIG. 6 also 
illustrates that mobile device 3 and desktop computer 
4 can be coupled to a wide area network 138 which can 
include simply another mobile device, another desktop 

15 computer, LAN 51 (shown in FIG. 2), WAN 52 (shown in 
FIG. 2), or any other suitable network. 

Similar items to those shown in FIG. 5 are 
similarly numbered. However, in FIG. 6, PIMs 5 and 7 
are shown in greater detail. FIG. 6 illustrates that, 

20 in one preferred embodiment, PIM 5 includes an 
electronic mail application 140, a calendar and 
scheduling application 142, and an abridged address 
book 144. Also, while each of the applications may 
have designated application programming interfaces, 

2 5 only a single API component 146 is shown in FIG. 6, 
for the sake of simplicity. 

FIG. 6 further illustrates that object store 6 
preferably interfaces with applications 140, 142 and 
144 through its own set of application programming 

30 interfaces 148. Thus, applications 140, 142 and 144 
maintain object store 6 by calling methods exposed by 
application programming interfaces 148 associated with 
object store 6. In addition, communication component 
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94 and sync component 99 communicate with application 
programs 140, 142 and 144 by calling methods exposed 
by application programming interfaces 146. 

PIM 7 in desktop computer 4 has also been 
5 illustrated as a more detail block diagram. In one 
preferred embodiment, PIM 7 includes electronic mail 
application program 150, scheduling and calendaring 
program 152 and full address book program 154. While 
each of the application programs 150, 152 and 154 may 
10 have an associated set of application programming 
interfaces, only a single application programming 
interface component 156 is illustrated in FIG. 6, for 
the sake of simplicity. 

FIG. 6 further illustrates that, in one preferred 
15 embodiment, object store 8 is associated with its own 
set of application programming interfaces 158 (which 
may also be the same as API 156, preferably MAPI, or- 
which may be separate therefrom). Thus, application 
programs 150, 152 and 154 call methods exposed by 
20 application programming interfaces 158 to maintain, 
and interact with, object store 8. In addition, 
communications component 115 calls methods exposed by 
application programming interfaces 156 to interact 
with application programs 150, 152 and 154. 
25 FIG. 6 shows that desktop computer 4 preferably 

includes electronic mail transport 160. Electronic 
mail transport 160 is preferably a commercially 
available electronic mail transport, such as a SMTP 
transport. However, it should be noted that desktop 
30 computer 4 can include any suitable transport, or 
combination of transports. 

FIG. 7 is a flow diagram illustrating the 
creation of a meeting request on mobile device 3. The 
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following description will proceed with reference to 

FIGS. 6 and 7. 

In order to create a meeting request from mobile 
device 3, the user first enters meeting request 
5 information through a suitable user interface. In one 
preferred embodiment, the user opens the scheduling 
application program 142 which causes a suitable user 
interface to be displayed on screen 84. Using stylus 
86, and possibly keypad 82 (or any other suitable 

10 input mechanism) , the user enters appropriate 
information to request a meeting. Such information 
will typically include the date and time of the 
meeting, the requested attendees (which may be entered 
by using a fully qualified electronic mail address, or 

15 by entering a familiar name, or selected from entries 
in a contacts database which have a non-empty 
electronic mail address field) , the subject matter of 
the meeting, an indication of whether the meeting is 
recurring or a single event, possibly the location of 

20 the meeting, and so on. Scheduling application 142 
creates an object representative of the meeting 
request . 

This information is used to create a meeting 
object and enter that object in the store associated 

25 with the calendar on mobile device 3. As a result of 
the creation of the meeting object, an electronic mail 
meeting request object is also created. It should 
also be noted that subsequent critical modifications 
to the meeting object will also cause updated 

30 electronic mail meeting request objects to be created 
and transmitted as well. 

In a preferred embodiment , a selection has 
already been made which specifies a transport by which 
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any electronic mail meeting request objects are to be 
sent. Alternatively, the transport to be used can be 
implicit in the full electronic mail address, itself. 
For example, it can be specified that any of 

5 transports 132-136 are to be used, when mobile device 
3 is to transmit the meeting request itself. In 
addition, a selection has also preferably already been 
made to specify certain options which are to be used 
in the sync protocol discussed above. For example, if 

10 an inbox synchronization option is enabled, the 
electronic mail meeting request objects will be 
synchronized to the outbox of desktop computer 4. 
Also, if a calendar synchronization option is enabled, 
the meeting object will be synchronized to the 

15 calendar of desktop computer 4 . Desktop computer 4 
then preferably transmits the electronic mail meeting 
request object synchronized to its outbox. 

The receipt of the meeting request information, 
from the user, and the creation of a meeting object 

20 representative of the meeting and an electronic mail 
meeting request object are indicated by blocks 162 and 
164 in FIG. 7. 

Next, the critical time stamp is added to the 
objects (as indicated by block 165) and scheduling 

25 application 142 assigns a global object identification 
tag to the meeting object created. The global object 
identification tag is a tag, such as a number, which 
uniquely identifies the object representative of the 
meeting request to mobile device 3, to desktop 

30 computer 4, and to all other devices which may 
encounter that object. The global identification tag 
is carried with the electronic mail meeting request 
object when it is transmitted, and remains with the 
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object on other devices. This is indicated by block 
166 . 

Because the electronic mail meeting request 
object must be transmitted to another device, 
5 scheduling application 142 calls methods in API" 146 
which manipulate electronic mail program 14 0 to 
retrieve a fully qualified electronic mail address for 
all of the potential attendees who are to receive the 
meeting request. In one preferred embodiment, 

10 scheduling application 142 obtains the fully qualified 
address directly from an address book. In another 
embodiment, mobile device 3 includes abridged address 
book program 144. In a preferred embodiment, abridged 
address book program 144 is implemented as a contacts 
15 feature provided by Microsoft Outlook 97. The 
abridged address book contains proper names, familiar 
names, addresses, telephone numbers, and fully 
qualified electronic mail addresses for people that 
the user has chosen to add to the abridged address 
20 book. Those people will likely be people who receive 
a significant number of electronic mail messages from 
the user of mobile device 3. Therefore, that 
information likely contains the fully qualified 
electronic mail addresses for the potential attendees 
25 of the meeting request. In addition, if the address 
is not fully qualified, the synchronization component 
97 on desktop 4 attempts to resolve the name on the 
desktop prior to sending the electronic mail 
transmission. 

30 Thus, either electronic mail application 140 or 

scheduling application 142 call methods in API 146 
which cause abridged address book program 144 to 
retrieve the fully qualified electronic mail address 
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for the familiar names entered by the user as 
potential attendees. This significantly alleviates 
memory overhead which would otherwise be required, for 
instance, if the user was required to download a full 
5 address book from desktop computer 4 in order to send 
an electronic mail message or a meeting request. This 
is indicated by block 168. In another preferred 
embodiment, the functionality associated with block 
168 is performed at block 162, as soon as the user 
10 inputs the appropriate information. 

Also, the transport option has preferably 
already been chosen which indicates the particular 
transport by which the electronic mail messages are to 
be transmitted. Those transports can be any of 
15 transports 132-136 on mobile device 3 or through 
synchronization with desktop computer 4, using one of 
its transports. Based on the option which has been 
chosen, the electronic mail meeting request object is 
transmitted through the appropriate transport and, 
20 once transmitted, is removed from the outbox of mobile 
device 3 . 

If the electronic mail meeting request object is 
to be sent directly from one of the transports on 
mobile device 3, the appropriate transport formats the 

25 meeting request for transmission . In a preferred 
embodiment, the particular properties which scheduling 
application program 142 attributes to an electronic 
mail meeting request object representative of a 
meeting request are compatible with multiple other 

30 PIMs. Therefore, these properties may be a subset or 
a superset, of all of the properties recognized by the 
multiple PIMs such that the object can be entertained 
and appropriately handled by those PIMs. - Appendix A, 
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which is attached hereto and forms a part of this 
document, is a list of message properties by which the 
MICROSOFT SCHEDULE + brand scheduling program defines 
objects associated with meeting requests. These 
5 properties notably include revised recurring 
notification properties which are backward compatible 
with other versions of MICROSOFT SCHEDULE + scheduling 
software. For instance, in the embodiment described 
in Appendix A, recurring notifications which are used 

10 to define recurring meetings are formatted as a 
superset of single-instance notifications. In this 
way, prior versions of the MICROSOFT SCHEDULE + 
scheduling software will be provided with well formed 
meeting notifications, even for recurring meetings. 

15 in the preferred embodiment, scheduling program 

142 then calls methods exposed by API 146 related to 
electronic mail application program 140. The 
electronic mail message which contains the electronic 
mail meeting request object is formulated into one of 

2 0 a predetermined number of classes by electronic mail 

application 140. The receiving scheduler program of 
the potential attendee differentiates between the type 
of meeting notification based on the mail message 
class. For example, in one preferred embodiment, mail 
25 message classifications exist for a meeting 
cancellation notice from the originator, a meeting 
request from the originator, a meeting acceptance from 
the attendee, a meeting declined from the attendee and 
a meeting tentatively accepted from the attendee. 

3 0 Thus, this is preferably included along with the 

object when the transport formats the electronic mail 
meeting request object for transmission. The meeting 
request is transmitted, through communications 
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component 94 to the designated transport 132, 134 or 
136 which, in turn, formats and transmits the message 
to network 13 8 . 

The formatting and transmission of the electronic 
5 mail meeting request object from a transport on mobile 
device 3 is indicated by blocks 172 and 174 in FIG. 7. 

After the electronic mail meeting request object 
is sent, it is removed from the outbox of mobile 
device 3 to indicate that the message has been sent. 
10 This is indicated by block 190. Upon next being 
coupled to desktop computer 4, the meeting object is 
synchronized to the store containing the calendar on 
desktop computer 4. Preferably, the PIMs also provide 
a feature which can be utilized to prevent the PIM 
15 from creating and sending an electronic mail meeting 
request object simply because the meeting object has 
been synchronized to the calendar on the desktop. The 
feature may simply be to only create electronic mail 
meeting request objects for meeting requests created 
20 on the desktop. This feature is implemented to 
further address the problem of duplicate messaging. 

If the transport option has been chosen to send 
the electronic mail meeting request object using the 
synchronization protocol and a mail transport on 
25 desktop computer 4, processing is substantially the 
same, except that the electronic mail meeting request 
object is synchronized to the outbox of desktop 
computer 4 (as indicated by block 173). Mobile device 
3 simply waits until it is coupled to desktop computer 
3 0 4 before any further action is taken with respect to 
that meeting request. Upon coupling of mobile device 3 
to desktop computer 4, the synchronization protocol 
described above is executed. During the 
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synchronization process, the meeting object is 
synchronized to the calendar on the desktop computer 4 
and the electronic mail meeting request object is then 
synchronized to the outbox of desktop computer 4 
5 through synchronization components 97 and 99. Upon 
receiving the electronic mail meeting request object 
indicative of the meeting request, electronic mail 
application program 150 recognizes that the meeting 
request needs to be transmitted. Electronic mail 

10 application program 150 calls the necessary methods 
exposed by API 158 to have the appropriate object 
transported, through communications component 115 and 
transport 160, to network 138. This is again 
indicated by blocks 172, 173, 174 and 190. 

15 it is also worth noting that, in one 

alternatively preferred embodiment, the meeting 
request need not be entirely formatted on mobile 
device 3. Instead, the data representing the 

electronic mail meeting request object can simply be 

2 0 stored and transferred during synchronization to 

desktop computer 4 where it is fully formatted. For 
instance, in one preferred embodiment, mobile device 3 
does not store the particular transport to be used by 
desktop computer 4 in sending the meeting request. 
25 Since this information is not stored by mobile device 
3, it is not synchronized with desktop computer 4. 
Instead, electronic mail application program 150 on 
desktop computer 4 (prior to sending the meeting 
request) calls the necessary methods through API 156 

3 0 to have full address book 154 retrieve the transport 

associated with each of the potential attendees 
identified by the user. That information is then used 
by electronic mail application program 150 in choosing 
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the appropriate transport 160 with which to transmit 
the electronic mail meeting request object. In this 
way, additional memory capacity need not be consumed 
on mobile device 3 to store such transport 
5 information. This is indicated by block 188. 

In any case, once electronic mail application 
program 150 causes the electronic mail meeting request 
object to be transmitted to network 138, it is removed 
from the outbox. This is indicated by block 190. 

10 After the electronic mail meeting request object 

has been sent it is determined whether any other 
meeting requests were synchronized with desktop 
computer 4 during the last synchronization process. 
If not , normal processing continues . If so, 

15 processing reverts back to block 172 wherein 
electronic mail application program 150 calls the 
necessary APIs to send the object. This is indicated 
by block 192. 

FIG. 8 is a flow diagram illustrating one 

20 preferred embodiment of how mobile device 3 handles 
responses to the meeting requests transmitted in 
accordance with FIG. 7. In the preferred embodiment, 
the addressee for responses to meeting requests is the 
meeting originator. Both senders and recipients of 

25 the meeting requests can be arranged properly for 
delegate handling. The publicly available MAPI 
specification fully discloses how to interpret such 
properties . 

Thus, the recipient of the meeting request is 
3 0 provided with a suitable user interface to indicate a 
response. The response is addressed to the meeting 
originator, or another proper delegate. The response 
is then transferred by the device which the recipient 
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is operating on and is received through one of 
transports 132, 134 or 136, or through communications 
component 94 on mobile device 3. This is indicated by 
block 194 in FIG. 8. 

5 Upon receiving the response, scheduling 

application program 142 correlates the response to the 
meeting object which was formed by scheduling 
application program 142 when the user created the 
request, and which is stored in object store 6. This 
0 correlation is performed by using the unique global 
identification number which uniquely identifies that 
meeting request to all devices which may encounter it. 
This is indicated by block 196. 

The critical time stamp information is then 
5 checked to determine whether the response corresponds 
to the latest meeting object. The response preferably 
actually contains two time stamps. The first is the 
recipient's opinion of the originator's critical time 
stamp. The second is a time stamp assigned by the 

20 recipient. The first is checked to determined whether 
it is the same as the originator's time stamp. If so, 
the response is considered to be in date. If not, the 
response is rejected or ignored as an out-of-date 
response. The second must be equal to or greater than 

25 any previously recorded time stamp from this 
particular recipient for the response to be in date. 
If not, the response is rejected or ignored as out-of- 
date. This is indicated by block 197. 

It should be noted that in the preferred 

3 0 embodiment, the time stamps are always moving forward. 
Thus, even if the user resets the clock sufficiently 
into the past, any subsequent time stamp is always the 
later of a current clock time and the last time stamp 
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plus one second. 

Scheduling application program 142 then calls the 
necessary methods exposed by API 148 in order to 
update the attendee status associated with the 
5 request. This is updated based on the particular 
response received from the attendee. This is 

indicated by block 198. 

Mobile device 3 then simply waits to be connected 
to desktop computer 4. Once it is connected, the 

10 updated objects (containing the updated attendee 
status property) are synchronized to the instance of 
that object stored in object store 8. This is 
accomplished utilizing the synchronization protocol 
discussed above. This is indicated by blocks 200 and 

15 202. The meeting, object is then available to 
scheduling application program 152 and desktop 
computer 4 to be displayed on the user's calendar at 
desktop computer 4 for user observation and 
interaction. 

2 0 FIG. 9 is a flow diagram which illustrates one 

preferred embodiment of how responses are handled when 
received through transport 160 on desktop computer 4. 

The user first inputs information through an 
appropriate user interface which defines the user's 
25 response to the meeting request. The response is then 
transmitted back to desktop computer 4 through 
transport 160 and communications component 115. This 
is indicated by block 204. 

Scheduling application program 152 correlates the 

3 0 response to the meeting object, as did mobile device 

3, by utilizing the global identification number 
assigned to the meeting object, and received along 
with the response to the meeting request. This is 
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indicated by block 206. The time stamp information 
is then checked to determine whether the response 
corresponds to the latest meeting object, again as 
described above. If not, the response is rejected or 
ignored as an out-of-date response. This is indicated 
by block 207. Scheduling application program 152 then 
calls the necessary methods exposed by API 158 to 
modify and update the attendee status of the meeting 
object stored in object store 8. This is indicated by 
block 208. Desktop computer 4 then simply waits until 
it is next coupled to mobile device 3 . 

At that point, the updated objects in object 
store 8 (which have been updated to accurately reflect 
the new attendee status based on the response) are 
15 synchronized to the other instance of that object then 
stored in object store 6. Synchronization is 
accomplished in accordance with the synchronization 
protocol discussed above. The updated object is then 
available for review and manipulation by the user of 
20 mobile device 3. This is indicated by blocks 210 and 
212 . 

The mobile device in accordance with an 
illustrative embodiment of the present invention also 
handles exceptions to recurring meetings and meeting 
25 cancellations. In one embodiment, the scheduling PIM 
erases all exceptions when an update to the recurrence 
pattern of a recurrent meeting is received. Thus, new 
electronic mail objects must be created and sent for 
each exception once a change in the recurrent meeting 
pattern has been sent. For instance, assuming the 
user entered a recurring meeting request on mobile 
device 3. Scheduling application 142 creates a 
recurring meeting object and enters it on -the calendar 
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of the user. Electronic mail application 140 also 
creates an electronic mail recurring meeting request 
object for transmission to potential attendees. The 
recipients (potential attendees) can respond generally 
5 as described above. 

For the sake of the present example, assume the 
recurring meeting is to occur every Tuesday from 
10:00-11:00 a.m. beginning on April 1. However, the 
user (originator) then needs to cancel the April 8 ch 
10 meeting. The user enters scheduling application 142 
and deletes the desired instance. Electronic mail 
application 14 0, in turn, creates another object for 
transmission which indicates this cancellation (which 
is an exception to the recurrence pattern) . The 
15 originator then needs to move the April 15th meeting 
to 11:00-12:00 noon. A similar process is executed to 
create this exception as well. Suppose then that the 
originator wishes to make a change to the location of 
the recurring meetings and apply the change to the 
20 entire recurrence pattern. This requires three new 
pieces of electronic mail to be transmitted. 

The first is simply created to indicate the new 
location which modifies the recurrence pattern. This 
may also, in some PIMs, erase the previous two 
25 exceptions. Thus, two new pieces of electronic mail 
are created to reinstitute the two exceptions (i.e., 
the cancellation of the April 8 th meeting and the time 
change for the April 15 th meeting) . These pieces of 
electronic mail are automatically created by 
30 electronic mail application 140. These same actions 
are taken in response to other suitable modifications 
as well, such as modification of the list of 
attendees. 
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LOCALIZATION 

As previously discussed, in the preferred 
embodiment, a meeting object is typically accompanied 
by a textual phrase which describes the nature of the 

5 meeting request. The textual phrase is generated 
based upon the property values input by the user 
during creation of the meeting request. For example, 
a user may request the potential attendees to attend a 
meeting on the third Monday of each month at 10:00 

0 a.m., and for a period which extends from January 1, 
2000, to March 20, 2001. In that case, a typical text 
message which might be retrieved and placed in the 
meeting request object to accompany that object for 
display to the potential attendees might read as 

5 follows: 

"This meeting shall take place on the third 
Monday of each month at 10:00 a.m. beginning January 
1, 2000, and ending March 20, 2001." 

However, in a different locality, convention may 

0 dictate that the day be placed before the month when 
reciting dates. Further, words or phrases in the text 
message, and the order of the components of the text 
message, may need to be rearranged in order to more 
closely conform to local convention. 

5 In the preferred embodiment, a predetermined text 

message of the type set out above is generated to 
describe each different type of recurring meeting 
which can be requested by the user of mobile device 3. 
In accordance with one aspect of the present 

\0 invention, the text messages used to describe requests 
for recurring meetings are broken down into a 
plurality of phrases. Each of the phrases which has 
been created is broken down into a plurality of 
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fields. The particular phrases which can be created 
to define a meeting request, and the particular fields 
into which those phrases are separated can be any 
suitable phrases and fields. 

For the phrase mentioned above, FIG. 11A 
illustrates one embodiment of the fields into which 
that phrase can be broken. FIG. 11A shows that a 
first portion of the phrase "This meeting shall take 
place on the third Monday of each month" is placed in 
field 214. The term "at" is placed in field 216. The 
time designation "10:00" is placed in field 218 and 
the AM/PM designator is placed in field 220. The term 
"beginning" is placed in field 222, and the remaining 
message is similarly broken up into fields 224, 226, 
15 228, 230, 234, 236, 238, 240 and 242. 

FIG. 10 is a flow diagram illustrating how the 
localization process works. The creation of the 
textual phrases defining meeting requests, and the 
breaking up of those requests into various 
20 predetermined fields, is indicated by block 242. 

Next, during manufacture of mobile device 3, a 
localizer program is run on mobile device 3 to 
rearrange fields 214-240, for each of the messages 
created, such that the messages conform to local 
25 convention. Of course, the specific localizer program 
which is run on mobile device 3 will depend on the 
particular locality and consumer base for which mobile 
device 3 is intended. Once the localizer program has 
been run, mobile device 3 contains a plurality of sets 
30 of fields, referred to as templates, into which 
message data is placed in order to display the textual 
message in a localized fashion. Running of the 
localizer program in setting up the templates 



is 
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indicated by block 244 . 

After mobile device 3 has templates which have 
been localized, mobile device 3 is ready to receive a 
meeting request and properly display the textual 
5 description of the meeting request. When a meeting 
request is received, the data stream indicative of the 
textual phrase which describes the meeting is also 
received by scheduling application program 142. This 
is indicated by block 246. Scheduling application 

10 program 142 parses the incoming data stream into 
values associated with the various fields in the 
appropriate template (the appropriate template 
corresponds to the specific textual description being 
received) . This is indicated by block 248. 

15 Next, the parsed data is placed into preselected 

fields in the templates based on the created phrases. 

This is indicated by block 250. Because the 
localizer program has already been run, the fields in 
the templates are already placed in appropriate order 

20 to conform to local convention. 

FIG. 11B illustrates the rearrangement of the 
fields in the template illustrated in FIG. 11A to 
conform to a different convention. FIG. 11B 

illustrates the conformation of the phrase to a 

2 5 convention in which the phrasing is slightly different 

from that shown in FIG. 11A, and in which the day is 
conventionally placed prior to the month in a date. 
The phrase now contains the same terms, but reads: 

"Beginning 1 January, 2000 and ending 20 March, 

3 0 2001 this meeting shall take place on the third Monday 

of each month at 10:00 AM. " 

All appropriate phrases will, of course, be 
similarly localized. 



SUBSTITUTE SHEET (RULE 26) 



WO 99/22324 PCT/US98/22413 



49 



10 



Also, in an illustrative embodiment, time zone 
information is handled in an advantageous manner. For 
instance, when a recurring meeting request is created 
and sent to a device located in a different time zone, 
the textual phrase indicative of the recurring meeting 
includes an indication of the time zone in which the 
recurring meeting request was created. For instance, 
if a user in Paris sends a recurring meeting request 
to a recipient in Seattle (nine hours different) for a 
meeting occurring every Tuesday at 8:00 a.m. beginning 
March 3, the textual phrase may be: 

"This meeting occurs every Tuesday at 8:00 a.m. 
beginning March 3; (GMT + 1) Paris, Madrid." 

This allows the recipient to view the recurrence 
15 pattern as originally composed by the sender. 

On the other hand, if the meeting is non- 
recurrent, the time is preferably simply displayed as 
the appropriate time for the recipient (e.g., "This 
meeting is scheduled for Tuesday at 11:00 p.m."). 

2 0 CONCLUSION 

Therefore, it can be seen that the present 
invention provides significant advantages over prior 
systems. First, the present invention allows the 
creation of a meeting request from a mobile device 
25 itself. The present invention further identifies the 
object associated with such a meeting request in a 
manner which uniquely identifies the object to all 
other devices likely to encounter the object. The 
present invention also utilizes a feature in the PIMs 

3 0 which indicates whether the meeting request has been 

sent to potential attendees. These features eliminate 
duplicate messaging. 

The present invention also preferably implements 
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features which reduce the memory required to implement 
the meeting request feature by use of an abridged 
address book. Further, the present invention 

preferably uses a set of scheduling properties which 
5 are compatible with a plurality of different PIMs 
likely to encounter the meeting request. In addition, 
the present invention preferably utilizes localization 
procedures which localize meeting requests to more 
closely conform to local convention and handle time 

10 zone information in an advantageous manner. The 
present invention also preferably supports the use of 
multiple electronic mail transports as well as a 
synchronization protocol. 

Although the present invention has been described 

15 with reference to preferred embodiments, workers 
skilled in the art will recognize that changes may be 
made in form and detail without departing from the 
spirit and scope of the invention. 
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APPENDIX A 



{autonumlgl } Audience/About this document 

This document describes the message properties used by Schedule* 2.0 to transmit meeting 
information to another Schedule* 2.0 user. The document also describes the Schedule* 1 .0 counterpart 
message properties (where appropriate). 

The reader should be familiar with MAPI, specifically properties stored on messages. The reader 
should also be somewhat familiar with MAPI 0 properties and how Schedule* 1.0 used them to 
transmit meeting information. 



{autonumlgl } Consumers 

This document is intended for third-party developers who plan to interact with Schedule* 2.0 via 
email. 



{autonumlgl } The Design 

Schedule*- 2.0 stores properties of a meeting in similarly typed MAPI properties in a message. 
Typically, the subject of the message matches the description of the meeting (as it did 1.0), and the 
body of the message contains the meeting notes (new for 2.0). The addressees of a meeting request or 
cancellation are compiled from the list of attendees in the_ meeting, filtered on who should actually 
receive this raaiL The addressee for meeting responses is the meeting originator. Senders and 
recipients are arranged properly for delegate handling. See the MAPI spec on how to interpret these 
standard properties. 

For mail systems that do not automatically handle delegation of mail, Schedule* 2.0 will open each 
addressee's schedule file (or equivalent) to determine if rr*:! iuould be sent to a delegate instead of or 
in addition to the intended recipient Also, Schedule* 2.0 will determine if the sending user is mailing 
on behalf of someone else and stamp appropriate properties into the message. The MAPI 1.0 
properties which control delegation are PR_SEhTr_REPRESEbrrtNG_(ENTRYID/NAME) and 
PR_RCVD_REPRESENTTNG_(ENTRYID/NAME). See the MAPI 1.0 spec on how these properties 
are set to induce delegation. 

Beyond the standard properties, Schedule* 2.0 defines and uses private properties which have no 
"normal" messaging counterpart There are two basic kinds of communication between a meeting 
organizer and an attendee: some notification related to a single meeting, or some notification related to 
a recurring meeting. For backward compatability, the recurring notifications are formatted as a 
superset of single-instance notifications. This way, Schedule* 1.0 users will at least see a well-formed 
meeting notification. 

As in version 1.0, Schedule* 2.0 differentiates the type of meeting notification by the mail message 
class. The class names have changed slightly since 1 .0. 



Version 1.0 Class name 


Version 2.0 class name 


Description 


IPM.Microsoft Schedule.MtgCncl 


IPM.Schedulc.Mecting.Canceled 


Meeting Cancellation notice. From 
originator 


IPM. Microsoft Schedule.MlgRcq 


IPM.Schedule.Mecting.Requesi 


Meeting Request. From originator 
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1PM. Microsoft 
Schedule.MtgRcspP 


IPM.Schcdulc.Mccting.Resp.Pos 


Meeting Acceptance. From 
attendee. 


IPM. Microsoft 
Schcdulc.MtgRcspN 


IPM.Schedule.Meeting.Resp.Neg 


Meeting Declined. From attendee 


IPM.Microsoft 
Schedule.MtgRespA 


iPM.Sdicdulc.Mccting.Rcsp.Tcnt 


Meeting Tentatively Accepted. 
From attendee 



{autonumlgl} Properties on Single Instance Meetings 

The following properties appear on all Schedule+ 2.0 messages and describe a single inst?nce of a 
meeting. For a recurring meeting requests, the single instance data will be the first instance of the 
recurrence. For recurrence exceptions, the data will be for that exception. 

Some of the following data is optional enly in that the notification remains useful even if the data is 
missing. Data that must be present and valid is marked as so. 

{autonumlgl J PRSTART_DATE 

UTC-adjusted starting date/time of the appointment Must be present. Uses Schedule+'s method of 
converting the time from the local timezone into UTC (the NT algorithm is buggy in that it uses the 
current system tinie to determine whether or not to consider Daylight adjustments). 

{autonumlgl } PRJENDJ)ATE 

UTC-adjusted ending date/time of the appointment Must be present 

{autonumlgl } PR_OW^EIl_C3UTTCAL_CHANGE 

This is an increasing value based on the time the appoinment date, time, or where data was last 
modified on the owner's schedule. It is used to insure responses and requests are processed in the 
correct order (mail receive or send order does not work properly). It is only ever changed by the owner 
of a meeting. It must be present on all meeting mail. 

{autonumlgl } PR_ATTENDEE_CRITICAL_CHANGE 

This is an increasing value based on the time of the last response sent by the attendee. It is used to 
insure responses are processed in the correct order (mail receive or send order does not work 
properly). It is only ever changed by the invited attendee of a meeting. It must be present on ail 
Meeting Responses. 

The idea behind the last two properties is that when a meeting request is sent, it contains in 
PR_OWNER_CRTnCAL_CHANGE the last modification time of the appointment according to the 
owner's clock. When a recipient reads the reequest, the value in PR_OWNER_CRITICAL_CHANGE 
is compared against the previous value (from a prior booking) to see if the request is still in date. If it 
is, the recipient may respond as desired. The response will have a copy of the same value in 
PR_0 WNER_CRITICAL_CHANGE and will stamp the current time in 

PR_ATTENDEE_CRIT1 CA L_CHANGE (according to the recipient's clock). When the owner reads 
the response, the PR_OWNER_CRITICAL_CHANGE will be compared against the timestamp stored 
in the appointment to decide if the response corresponds with this version of the appointment. Then, 
PR_ATTENDEE_CRITICAL_CHANGE is compared against any prior timcsiamp for responses 
received from this user to decide if the response itself is current. 
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{autonumlgl } PRJVHERE 

A descriptive string describing where the meeting will be held (no 1.0 counterpart). The text of this 
string will also appear in the body of the note so that non-Schcdule+ users will still see some useful 
information. In 2.0, the embedded body text will be removed before it is displayed or written into the 
schedule. 

{autonumlgl } PR_CLOBAL_OBJID 

a "global" ID for the meeting. This ID uniquely and universally ID'S the meeting or recurrence pattern. 
Its internal structure is: 

+0 bytes: GUID idenitfying client vendor. For Microsoft Schedule*- 2.0, this GUID is 

0x04, 0xu2, OxEO, 0x74, 0xC5, 0xB7, 0x10, 0x1 A, 
0x82, OxEO, 0x08, 0x00, 0x2B, 0x36, 0xA3, 0x33 

Other vend-as should use their own GUID. 

+16 bytes: Implementation specific data. 

If this property is missing, the attendee tracking features will be disabled. This means further 
notifications concerning this meeting will not be properly handled by the recipient, and the 
recipient will not be able to communicate attendee status properly with the originator. 

(autonumlgl } PR_REQUIRED_ATTENDEES 

If present, lists all the invited 4 *required m attendees. The string is a concatenated form of the display 
names of each required attendee, separated by semicolons. The intent is the string itself may be placed 
in the "To:" well of a mail message when the original meeting request is Replied or Reply-AlPed, ai* J 
the names will directly resolve into real recipients. 

{autonumlgl } PR_OPTlONAL_ATTENDEES 

If present, lists all the invited "optional" attendees. The string is a concatenated form of the display 
names of each optional attendee, separated by semicolons. The intent is the string itself may be placed 
in the **CC:" well of a mail message when the original meeting request is Replied or Reply-All 'ed, and 
the names will directly resolve into real recipients. 

{autonumlgl } PR_RESOURCE_ATTEND EES 

If present, lists all the invited "resource" attendees. The string is a concatenated form of the display 
names of each resource attendee, separated by semicolons. The intent is the string itself may be placed 
in the **BCC:" well of a mail message when the original meeting request is Replied or Reply-All f cd, 
and the names will directly resolve into real recipients. 

{autonumlgl} PRJ>ROCESSED 

If present and TRUE, indicates that the message's contents have been processed (ie, for responses, the 
user's response code has been incorporated back into the owner's schedule). This property is not 
transmitted and is written only by the Schedule+ 2.0 client after the message has successfully been 
processed. 
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{autonumlgl } PR_IS_SILENT 

If present and TRUE, indicates that the message's contents are intended solely for the Schedule* 2 0 

S ^ lS T C ° mCn( ° f intCrest for * c oscr - ™* WS«Hy ^Pli« to response mail in 

vouch the attendee didn t type anything into the message body for the meeting owner to read 
I nerefore, the mail should be processed and deleted automatically. 

{autonumlgl } PR_WANT.SILENT.RESP 

V*u i S !""! i Wi£h PR -RESPONSE_REQUESTED. It is expected that messages from 

Schedule* 1.0 will not have this property. Unless this property is present and TRUE, responses will 
only be s«t if PR_RESPONSE_REQUESTED is also present and TRUE. Also, those responses will 
F/ULSE) 1 n0IHSiiCnt ^ PR - IS - SILENT ' m * c response will be either missing or 

{autonumlgl } PRJDELEGATE__MAIL 

If present and TRUE, indicates that the message was sent as part of Schedule* 2.0's sender-side 
delegation strategy. If someone receives a piece of mail without this property marked true, but does 
have someone listed as being a delegate, the mail will automatically be forwarded to that delegate 
This scenario can happen if someone sends a piece of mail, and the recipient adds someone as a 
delegate before the mail is received (but after it has been sent). 

{autonumlgl } Properties used with Schedule* 1.0 

The properties listed here need to be translated on the fly to/from the old 1.0 format when the message 
is converted to/from Mail 3.0 form. This happens by the TNEF converter in MAPI, and shouldn't be 
the concern of any other developerr. 

{autonumlgl } P^JUiSPONSEJREQUESTED 

If present and TRXJE, indicates that the meeting owner has requested that attendees send a response 
with meaningful text (ie, PRJS_SILENT is expected to be false). If the property is missing or FALSE 
it indicates the sender (owner) is not interested in any response details beyond the actual response 
code. The recipient (attendee) will not be given the option to write up response mail. However a 
response message will be sent and auto-processed by the owner (PR IS_SILENT will be true) ' The 
recipient will be able to override this behavior with a menu option. ~ 

{autonumlgl } PR_OWNER_APPT_ID 

A Schedule* 1.0-spefic form of an appointment ID. Schedule* 2.0 will write a semi-valid ID here 
(only m that it probably won't cause problems when communicating with 1.0). Other clients should 
leave this property blank. 

{autonumlgl } Properties on Recurring Meetings 
{autonumlgl } PR_ISJRECURRING 

If present and TRUE, indicates that this meeting request contains all the following data, 
{autonumlgl } PRJSJEXCEPTION 

If present and TRUE, indicates that this request is for a single instance of a pattern. 
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{autonumlgl } PR_SINCLEJNVITE 

If present and TRUE, indicates that this request is an invitation to the single instance only. The 
recipient is not invited to the rest of the pattern. 

{autonumM J PRJNME_ZONE 

Dcsribes the owner's time zone (TBD - no work on time zones has been done yet). Must be present for 
recurring meeting requests. 

{autonumlgl } PR_STARTRECURJ»ATE 

The start date of the recurrence pattern in the originator's local time zone. It's encoded by: 
((long)ymd.yr * 1 61 + flong)ymcLmon) * 321 + Oong)ymd.day. It's stored as a long so gateways wonH 
interpret the date as if it were in GMT and possibly muck with it Must be present for recurring 
meeting requests. 

{autonumlgl } PR_START_RECURJTIlVfE 

The start time of the pattern in the originator's local time zone encoded by: ((long)time.hr • 641 + 
(long)timejnb) * 641 + (Iong)timejec. Same reason for encoding. Must be present for recurring 
meeting requests. 

{autonumlgl } PR_END_RECUR_DATE 

If present, holds the end date for the pattern. If missing, the pattern runs forever. See 
PR_START_RECURJDATE for encoding method. 

{autonumlgl } PRJENDJRECURJTfME 

The end time of the pattern. See PR_START_RECUR_TIME for encoding. Note that unless the first 
instance of the pattern is an exception, the start date/time and end time for the pattern will coincide 
with PR_START_DATE and PR_END_DATE in this message. Must be present for recurring meeting 
requests. 

{autonumlgl } PRJ30WJPREF 

Describes the 1st day of w~k user preference. This is for multi-day weekly patterns that have an 
interval greater than one. Imagine a pattern that's every two weeks on Sunday and Monday starting on 
the 1st If the first day of week is Sunday the 1st, the pattern will consist of 1,2, 15, 16, etc. If the first 
day of week is Monday, the pattern will be 2, 8, 16, 22, etc. Must be present for recurring meeting 
requests which describe a weekly pattern where the week interval is greater than I. 

{autonumlgl } PR_RECUR_TYPE 

Describes the type of recurrence. One of trecurDaily (0x40), trecurWeekly (0x30), trccurMonthly I 
(OxOC), trecurMonthly2 (0x38), trecurYearlyl (0x07), trecurYcarly2 (0x33). Must be present for 
recurring meeting requests. 

{autonumlgl } PR_DAY_INTERVAL 

Describes the delta in days between instances of this pattern. If missing and required for the pattern 
type, it is assumed to be 1. ■ 

{autonumlgl } PRWEEKINTERVAL 

Describes the delta in weeks between instances of this pattern. If missing and required for the pattern 
type, it is assumed to be 1 . 

{autonumlgl } PR_MONTH_INTERVAL 

Describes the delta in months between instances of this pattern. If missing and required for ihe pattern 
type, it is assumed to be 1 . 
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{autonumlgl } PR_YEAR_INTERVAL 

Describes the delta in years between instances of this pattern, if missing and required for the pattern 
type, it is assumed to be I. 

{autonumlgl J PRJDOWJVMSK 

Bit field (bit 0 ~ Sunday) which describes which days or the week are valid in this partem. I f missing 
and required for the pattern type, it is assumed to be 2*-l (all days). 

{autonumlgl } PR_DOM_MASK 

Bit field (bit 0 « day I) which describes which days of any given month are valid in this pattern, if 
missing and required for the pattern type, it is assumed to be 2 32 -l (ail days). 

{autonumlgl } PRJVfOYJVlASK 

Bit field (bit 0 = January) which describes which months in any given year are valid in this pattern. If 
missing and required for the pattern type, it is assumed to be 2 -1 (all months). 
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Appendix A: Property Definitions 

Properties defined by MAPI for S+ backwards compatibility: 



PRSTART DATE 
PR_END_DATE 
PR_RESPONSE_REQUESTED 
PR_OWNER_APPTJD 

Non-transmitted properties used by S+: 

define PR.PROCESSED PROP_TAG( PT_BOOLEAN, Ox7d0I) 

We use named properties for the remaining definitions. 

QUID = {0X6ED8DA90, Ox450B, OxlOlB, 0x98, OxDA, 0x00, 0xAA,.0x00, 0x3F, 0x13, 0x05} 



Name 


LID 


PropTypc 


ATTENDEE CRITICAL CHANGE 


I 


PTSYSTIME 


WHERE 


2 


PTJTSTRING 


GLOBAL OBJID 


3 


PTJ3INARY 


IS_SILENT 


4 


PT.BOOLEAN 


IS_R£CURRING 


5 


PTJBOOLEAN 


REQUIRED_ATTENDEES 


6 


PTJTSTRING 


OPTTONAL_ATTENDEES 


7 


PTJTSTRING 


RESOURCE ATTENDEES 


8 


PTJTSTRING 


DELEGATE MAIL 


9 


PTBOOLEAN 


^EXCEPTION 


10 


PTBOOLEAN 


SINGLEJNVITE 


11 


PT BOOLEAN 


TIME_ZONF 


12 


PTJ4 


START_RECUR DATE 


13 


PT 14 


START_RECUR__TtME 


14 


PTJ4 


END_RECUR DATE 


15 


PT~I4 


END_RECURJTIME 


16 


PT_I4 


DAY^INTERVAL 


17 


PT 12 


WEEKJNTCRVAL 


18 


PT 12 


MONTH_INTERVAL 


19 


PTJ2 


YEARJNTERVAL 


20 


PTJ2 


DO\V_MASK 


21 


PT 14 


DOM_MASK 


22 


PT 14 


MOY_MASK 


23 


PT 14 


RECURJTYPE 


24 


PT_12 


DOW_PREF 


25 


PTE 


OWNER_CRITICAL_CHANGE 


26 


pt"systime 



V 
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Appendix B: Mapping from Schedule* 1.0 properties " 

following tabic associates the Schedule* J.O message properties to their 2.0 counterparts All of 
these properties are defined by MAPI 1.0 for backwards compatibility. Please see the 35l 1 0 
documentation for a description of the PR SENT REPRESENTING * and eSCCUIeMAPI 10 
PR_RCVD^REPRESENTING * propertied " 



Scheduled 1.0 
attOwner 



Schedule* 2.0 



if msg is a mtg req or cancellation: 

PR_SENT_REPRESENTTNG_(ENTRYID/NAME) 
otherwise: 

PR^RCVD_REPRESENTING_(ENTRYI D/NAM E) 
only if msg is not a mtg req or cancellation 

PR_SENT_REPRESENT1NG_(ENTRYID/NAME) 
no counterpart 

no counterpart (string recomputed from other data) 

no counterpart 

PR_STARTDATE 

PR_END_DATC 

PR.OWNER^APPTJD 

PR_RESPONS E_REQUEST£D 



attSentFor 

attDelegate 

attWhen 

attAidLoca! 

attDateStart 

attDateEnd 

attAidOwner 

attRequestRes 
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Appendix C: Schedule* 1 



ffdcfmc attOwner 
^define attScntFor 
#definc attDelegate 
#define art When 
^define attAidLocal 
tfdefine attDateStart 
#defme attDateEnd 
#define attAidOwner 
#define attRequcstRcs 



.0 property definitions 

FormAtt ( iattClientMin+O, atpBytc ) 
FormAtt ( iattCiientMin+ 1 ; atpBytc ) 
FomiAtt ( iattCHentMin+2, atpBytc } 
FormAtt ( iattClientMin+4, atpString ) 
FormAtt ( iattCIicntMin+5, atpLong ) 
FormAtt ( iattClicntMin+6, atpDatc ) 
FormAtt ( iattClientMin+7, atpDatc ) 
FormAtt ( iattCIientMtn+8, atpLong ) 
FormAtt ( iattClientMin-^, atpShort ) 



See the MAPI 0 documentation forme meaning of these macros. 
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* SPLUSTAGS.H 

Property tag definitions for standard properties of Schedule+ 2 0 

* objects. 



Copyright 1986-1997 Microsoft Corporation. All Rights Reserved. 



Sifndef SPLOSTAGS_H 
fcdefine SPLUSTAGS H 



^define HHPR_START_DATE 
IME, 0x0060) 
#define HHPR_END_DATE 
I ME, 0x0061) 
#define HHPR_OWNER_APPT ID 
0x0062) 

# define HHPR_RES PONS E_REQUES TED 
0x0063) 

#define HHPRJDWNER_CRITICAL CHANGE 
LETIME f . 0x0064) 

#define HHPR_ATTENDEE_CRITICAL CHANGE 

LETIME, 0x0065) 

#define HHPR_WHERE 

WSTR, 0x0066) 

#define HHPR_GLOBAL_OBJID 

OB, 0x0067) 

#define HHPR_REQUIRED_ATTENDEES 
WSTR, 0x0068) 

#define HHPR_OPTIONAL_ATTENDEES 
WSTR, 0x0069) 
#define HHPR__RESOURCE_AT TEN DEES 
WSTR, 0x006a) 

#define HHPR_IS_SILENT 
0x006c) 

tfdefine HHPR_WANT_SILENT_RESP 
0x006d) 

#define HHPR_DELEGATE_MAIL 

0x006e) 
#define HHPR__IS_RECURRING 

0x006f) 
^define HHPR_IS_EXCEPTION 

0x0070) 
#define HHPR_SINGLE_INVITE 

0x0071) 
^define HHPR_TIME_ZONE 

0x0072) 

^define HHPR START RECUR DATE 



PROP_TAG< PT_SYST 
PROP_TAG( PT_SYST 
PROP TAG ( PT LONG 



PROP_TAG ( 


CEVT_ 


12 


PROPJTAG ( 


CEVT_ 


_FI 


PROP_TAG { 


CEVT_ 


_FI 


PROP_TAG ( 


CEVT_ 


LP 


PROP_TAG ( 


CEVT_ 


BL 


PROFIT AG ( 


CEVT_ 


LP 


PROP_TAG ( 


CEVT_ 


LP 


PROP TAG ( 


CEVT 


LP 



PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG{ CEVT_I2 
PROP_TAG( CEVT_I2 
PROPJTAG( CEVT_I4 
PROP TAG ( CEVT 14 » 
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0x0073) 

((define HHPR_START_RECUR TIME 

0x0074) ~ 
ff define HHPRJEND_RECUR DATE 

0x0075) 

fldefine HHPRJSND_RECUR TIME 

0x0076) 
#d«fine HHPR_DOW_PREF 

0x0077) 
Sdefine HHPR_RECUR_TYPE 

0x0078) 
#define HHPR_DAY_INTERVAL 

0x0079) 
#define HHPR_WEEK_INTERVAL 

0x007a) 

^define HHPR_MONTH_INTERVAL 

0x007b) 
^define HHPR_YEAR_INTERVAL 

0x007c) 
#define HHPR_DOW_MASK 

0x007d) 
#define HHPR_DOM MASK 
/ 0x007e)~ 
#define HH PR_MO Y_MAS K 

0x007i") 

// Non-transmitted property (not naraed) 
#defxne HHPR_PROCESSED 
0x7d01) 

#ifndef hhpr__ta^_c::ly 

static ULONG SPlusNamedTagTypes [30] = f 
PT_SYSTIME, X 
PT__STRING8 , 
PT_BINARY, 
PTJ30OLEAN, 
PTJSOOLEAN, 
PT_STRING8, 
PT_STRING8, 
PT_STRING8, 
PT_BOOLEAN, 
PT_BOOLEAN, 
PT_BOOLE AN , 
?T_I4, 
PT_I4, 
PT_I4, 
PT_I4, 
PT_I4, 
PT_I2, 
PT_I2, 
PT_I2, 



PROP_TAG( CEVT_I4 
PROP_TAG( CEVT_I4 
PROP_TAG( CEVT_I4 
PROP_TAG( CEVT_I2 
PROP_TAG< CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I2 
PROP_TAG( CEVT_I4 
PROP_TAG( CEVT_I4 
PROP_TAG( CEVT_I4 

PROP_TAG( CEVT 12 
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PT_I2, 

PT_I4, 

PT_I4, 

PT_I4, 

PT_I2, 

PT_I2, 

PT_SYSTIME, 

PT_SYSTIME, 

PT_SYSTIME, 

PT_BOOLEAN, 

PT_I4 }; 

static ULONG SPlusNamedTags f 30) « { 
HHFR_ATTENDEE CRITICAL CHANGE, 
HHPR_WHERE, ~ 
HKPR_GLOBAL_OB JI D , 
HHPR_IS_SILENT, 
HHPR_ISJRECURRING, 
HHPR_REQUIRED_ATTENDEES, 
HHPR_OPTIONAL_ATTENDEES , 
HHPR_RESOORCE_ATTENDEES , 
HHPR_DELEGATE_MAI L , 
HHPR_IS_EXCEPTION, 
HHPR_SINGLE_INVITE, 
HHPR_TIME_Z0NE, 
HHPR_START_RECUR_DATE , 
HH PR_START_RECUR_TIME , 
HHPR_END_RECOR DATE, 

HHPR_END_RECUR JTIME , 

HHPR_DAY_I NTERVAL , 

HHPR_WEEK_I NTERVAL , 

HHPR__MONTH_lNTERVAL , 

HHPR_YEAR_INTERVAL, 

HHPR_DOW_MASK, 

H H PR_DOM_MAS K , 

H H PR_MO Y_MAS K , 

HHPR_RECUR_TYPE , 

HHPR_DOW_PREF / 

HHPR_OWNER_CRITICAL CHANGE, 

HHPR_START_DATE , 

HHPR_END_DATE, 

H H PR_RES PONS E_REQUES TED, 

HHPR_OWNER_APPT_ID} ; 

#endif // HHPR_TAG_ONLY 
#endif /* SPLUSTAGS H */ 
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WHAT IS CLAIMED IS: 

1. A mobile device, comprising: 
an object store; 

an application program configured to maintain 

objects on the object store; 
a user input mechanism configured to receive 

user input information; 
a synchronization component configured to 

synchronize individual objects stored on the 

object store with remote objects stored on a 

remote object store; 
a communications component configured to 

communicate with a remote device containing 

the remote object store; and 
wherein the application program is further 

configured to generate a meeting object and 

an electronic mail meeting request object 

based on the user input information. 

2. The mobile device of claim 1 wherein the 
application program is configured to generate the 
meeting object with a global identifier property 
uniquely identifying the meeting object among a 
plurality of other objects. 

3. The mobile device of claim 2 wherein the 
application program comprises: 

a first application program configured to 

generate the meeting object based on the 
user input information; and 

a second application program configured to 

generate the electronic mail meeting request 
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object . 

4. The mobile device of claim 1 wherein the 
application program further comprises: 

a contacts application program configured to 
maintain objects on the object store 
indicative of contact information wherein 
the contact information includes address 
information indicative of a fully qualified 
electronic mail addresses for individuals 
identified by the contact information; and 

wherein the application program is configured to 
obtain the fully qualified electronic mail 
.address of potential attendees identified by 
the contact information by interaction with 
the contacts application program. 

5. The mobile device of claim 1 wherein the 
application program is configured to generate the 
meeting object and the electronic mail meeting request 
object such that properties of the objects are 
compatible with at least a second application program 
associated with the remote object store and different 
from the application program. 

6. The mobile device of claim 1 wherein the 
application program is configured to receive a data 
stream indicative of a textual phrase describing the 
meeting object, to parse the data stream into sections 
and place the sections in corresponding fields of a 
preselected template containing the fields, the 
preselected template being associated with the textual 
phrase received. 
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7. The mobile device of claim 6 wherein the 
preselected template is created by arranging the 
fields in an order, the order being based on a 
specific locality. 

8. A method of operating a mobile device, 
comprising: 

providing a first object store on the mobile 
device ; 

providing a first application program on the 

mobile device; 
maintaining objects in the first object store 

with the first application program; 
intermittently synchronizing the objects in the 

first object store with objects in a remote 

object store; 
receiving user input information indicative of a 

meeting request; 
generating a meeting object with the first 

application program such that at least some 

of the user input information defines 

properties in the meeting object; 
generating an electronic mail meeting request 

object based on the information in the 

meeting object; and 
storing the meeting object and the electronic 

mail meeting request object in the first 

object store for transmission. 

9. The method of claim 8 wherein synchronizing 
comprises: 

coupling the mobile device to a computing device 
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having the remote object store; 
synchronizing objects in the first data store 

with objects in the remote data store; and 
transmitting the electronic mail meeting request 

from an electronic mail transport on the 

computing device. 

10. The method of claim 8 and further comprising: 
providing an electronic mail transport on the 

mobile device; and 
transmitting the electronic mail meeting request 
object through an electronic mail transport 
on the mobile device. 



11. The method of claim 10 wherein providing an 
electronic mail transport on the mobile device 
comprises : 

providing a plurality of electronic mail 
transports on the mobile device; and 

selecting one of the plurality of electronic mail 
transports through which the electronic mail 
meeting request objects are to be 
transmitted . 

12. The method of claim 11 wherein generating a 
meeting object further comprises: 

assigning the meeting object a time stamp 
indication indicating a time when the 
meeting object was created; and 

wherein generating the electronic mail meeting 
request object includes assigning the 
electronic mail meeting request object the 
time stamp indication. 
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13. The method of claim 12 and further comprising: 
receiving response objects; 

correlating the response objects with the meeting 
object on the mobile device based on the 
global identifier and the time stamp 
indication; and 

updating a response status associated with the 

meeting object based on the response objects 
received . 

14. The method of claim 13 and further comprising: 
synchronizing the response status with the remote 
object store. 

15. A data transmission system, comprising: 
a first computing device including: 

a first data store configured to store objects; 
a user input mechanism; and 

a first application program configured to receive 
user input information from the user input 
mechanism, create a first object based on 
the user input information and store the 
first object on the first data store; 

a synchronization manager configured to 

synchronize objects in the first data store 
with objects in a second data store; 

a second computing device including: 

the second data store, the second data store 
being configured to store objects; and 

a second application program configured to access 
the second data store and create an 
electronic mail object based on the first 
object being synchronized to the second data 
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store from the first data store; 
an electronic mail transport; and 
wherein the second application program is 

configured to transmit the electronic mail 
objects with the electronic mail transport. 

16. The system of claim 15 and further comprising: 
a third computing device including: 

a third data store configured to store objects; 
and 

a third application program configured to access 
the third data store, to receive electronic 
mail objects from the second computing 
device and to store the electronic mail 
objects on the third data store. 

17. The system of claim 16 and further comprising: 
a fourth computing device including: 

a fourth data store; and 

a fourth application program configured to 
access the fourth data store and store 
objects on the fourth data store; and 

wherein the synchronization manager is 

configured to synchronize objects in 
the third and fourth data stores. 

18. The system of claim 17 wherein the 
synchronization manager comprises: 

a first synchronization manager on at least one 
of the first and second computing 
devices; and 

a second synchronization manager on at least one 
of the third and fourth computing 
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devices . 

19. A mobile device, comprising: 
an object store; 

a user input mechanism configured to receive user 

input values; 
a plurality of electronic mail transports; and 
a first application program configured to create 
an object based on the user input values and 
to transmit the object using a preselected 
one of the electronic mail transports. 

20. The mobile device of claim 24 and further 
comprising : 

a housing sized to hold the object store, the 
application program and the plurality of 
electronic mail transports and to fit in the 
hand. 
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